Koppel-wattus? Welkom in de wereld van bus, tram en metro

OV reisinformatie voor nerds: Deel 1

Joel Haasnoot – Vrijwilliger NDOVLoket

Anno 2016 is de wereld van openbaar vervoer enorm open: heel veel data wordt gedeeld door de OV-bedrijven volgens Nederlandse standaarden. Vandaag heet ik je welkom in de wereld van bus, tram en metro (grofweg: veerboten soms ook). Trein behandelen we in een andere blogpost, dat is namelijk een compleet andere wereld.

OV-Vervoerders delen reisinformatie meestal omdat dit verplicht wordt door opdrachtgevers. Het proces om deze data vrij te peuteren duurt vele jaren, over veel lichtingen aanbestedingen heen. Het is niet makkelijk om overheden, vervoerders en leveranciers allemaal samen te laten werken. De data wordt geleverd volgens standaarden die we in Nederland hebben opgezet. Deze standaarden heten koppelvlakken en zijn gemaakt door de vervoerders en leveranciers, verenigd in werkgroep Bison, onderdeel van de organisatie Connekt.

Elk koppelvlak is gemaakt voor een ander stukje of type data en heeft een nummertje gekregen. De laatste versie van elke standaard staat op de site van Bison, hier. Hierbij even een bloemlezing met wat elk koppelvlak doet en wat je in de praktijk tegenkomt. Ik ga het niet in de juiste volgorde doen, omdat sommige standaarden in de praktijk niet publiek zijn of niet worden gebruikt:

Koppelvlak 1 (KV1)

Dit is de dienstregeling of planning van een vervoerder zoals deze van te voren wordt gepland. Dat wil zeggen: alle lijnen waar bussen, trams of metro’s op rijden, de haltes waar ze stoppen, op welke dagen en op welke tijden ze rijden en nog meer. Dat nog meer is onder andere: bestemmingen, lijnkleuren, wie de lijn betaalt (welke overheid), en hoe de bus rijdt. In de praktijk is dit niet voor het hele jaar zoals je in een busboekje vindt maar een aantal weken vooruit, inclusief de geplande uitzonderingen. Over uitzonderingen en hoe die wel en niet werken volgt nog een keer een blog.

Qua bestand is KV1 een collectie verschillende CSV bestanden of tabellen die allemaal net iets andere data bevatten. De standaard legt uit welke velden hierin verplicht zijn of niet en wat er in welk veld moet staan.

De praktijk is helaas wel iets lastiger omdat veel vervoerders het allemaal net even anders doen. KV1 inlezen van een vervoerder is makkelijk, maar er zijn dus nogal wat uitzonderingen. KV1 wordt door partijen als OVapi ook omgezet naar Google Transit Feed Specification, GTFS: dat is voor een starter makkelijker mee te werken (212MB: je wilde alles toch?). Over de GTFS standaard volgende keer meer.

KV6

Bijna elke bus heeft tegenwoordig een GPS apparaat en die posities sturen vervoerders door met 3 of 4G verbindingen. Niet alleen om zelf de bussen te kunnen beheren, maar ook voor reisinformatie door, jawel, koppelvlakken. Een bus die rijdt levert dus XML-berichtjes op met daarin informatie over de status van een busrit. Dat is dus een rit die in KV1 gepland is.

De berichtjes worden verstuurd aan de hand van bepaalde gebeurtenissen: onder andere voor het begin van een rit, het aankomst en vertrek op een bushalte, het rijden van de route tussen die haltes, het afwijken van de geplande route en tenslotte het einde van de rit. De meeste van deze berichten bevatten ook de GPS posities, maar niet elk bericht bevat die informatie.

Met KV1 en KV6 kan je ook je eigen actuele reisinformatiesysteem bouwen, en dat is precies wat de overheden dan ook hebben gedaan om de displays bij bushaltes aan te sturen (in OV-jargon heet zo’n scherm een DRIS). OVInfo (op iOS en Android) doet dit zelf ook, maar gebruikt de informatie bijvoorbeeld voor ovradar.nl, om te tonen waar de bussen rijden op dit moment. Je kan de real-time stroom van XML-berichtjes ontvangen via het NDOV-loket, hoe dat gaat vertellen we volgende keer.

KV17

Goed, dus we hebben nu bussen die rijden volgens een dienstregeling (KV1) op een bepaalde plek (KV6). Maar wat als dat nu eens niet het geval is, bijvoorbeeld door een ongeluk, staking of ander probleem? Dan stuurt de vervoerder met KV17 een berichtje om aan te kondigen dat de rit niet meer rijdt. Of als dan even later de bus toch rijdt, kan dat ook.

Er zitten in deze standaard nog wat andere mogelijkheden, bijvoorbeeld haltes die niet worden aangedaan of een rit die half rijdt. In de praktijk zijn die berichten nog niet echt wijdverspreid, vooral Connexxion gebruikt die mogelijkheden.

KV15

En wat als er wat anders gebeurt dat nu of in de toekomst belangrijk is voor klanten? Vervoerders kunnen met KV15 een semi-gestructureerd bericht sturen met informatie. Vaak zie je deze op de bushalte in de vorm van een scrollend bericht of een app als waarschuwing. Ik zeg semi-gestructureerd omdat er 255 tekens vrije tekst in kan, ondersteund door een aantal vaste waardes over het bericht (zoals de oorzaak, gevolg, etc.). Deze berichten hebben ook een begin- en einddatum en tijd en worden verstuurd per halte.

KV7/8

Om te communiceren over de geplande info in de actuele situatie zijn KV7 en KV8 in het leven geroepen. Dit wordt met name gebruikt om de DRIS-schermen aan te sturen, maar je kan dit ook gebruiken om actuele vertrektijden te maken. Iemand heeft in dat geval namelijk al het klusje voor je gedaan om KV1, KV6, KV17 en KV15 te combineren. In het geval van OpenOV kan je dit afnemen in het iet wat bizarre formaat “KV78turbo”, waarbij je realtime berichten gepushed krijgt als afnemer. De berichten hebben een soort CSV formaat. Er is een wat verouderde voorbeeld implementatie is open source beschikbaar op Github (hij is wel lastig te installeren).

KV19

Deze ga je in de praktijk niet echt tegenkomen: de enige actieve gebruiker is 9292. Het is een manier om vertrektijden te publiceren naar displays en schermen. Voor meer info zal je de specificatie en Bison architectuur moeten lezen (en dat is sowieso een goed idee).

KV4/5

Dit gaat over het toewijzen van bussen aan perrons. Bijvoorbeeld het busstation in Leiden kunnen de bussen stoppen aan een ander perron als het druk is, of juist niet. Er zijn weinig andere voorbeelden van dit soort busstations, dus wordt het ook niet veel gebruikt. Ook wordt deze informatie nog niet publiek beschikbaar gesteld, maar het zou in de toekomst wel handig kunnen zijn om aan reizigers te vertellen op welk perron de bus straks stopt – wanneer dit dynamisch wordt gewezen, in plaats van in de dienstregeling staat.

 

Goed, dat was het voor nu. De laatste paar standaarden in de tabel zijn grotendeels “niet van toepassing” – ze worden niet actief toegepast of zijn niet publiek beschikbaar. Volgende keer gaan we verder met welke andere tools en standaarden handig zijn. Voor aflevering drie staan de informatiebronnen van treinen op de rol.

Tarieven 2017

Conform de loketovereenkomst melden we drie maanden voor een nieuwe peildatum onze tarieven. Een wijziging stelt afnemers in staat om de overeenkomst met ons loket per direct op te zeggen. We hebben er voor gekozen om ook dit jaar geen wijzigingen door te voeren. Als nieuwe afnemer van de standaard dienstverlening zult u dan ook bij aanmelding geen factuur ontvangen voor 2017.

We hebben in de afgelopen periode een aantal vragen gehad over de hoeveelheid afnemers van ons loket; op dit moment zijn er 184 afnemers die het aanmeldproces succesvol hebben doorlopen en waar we een getekende overeenkomst van hebben ontvangen. Het aantal IP adressen dat actuele reisinformatie kan afnemen, omdat zij in de firewall is opgenomen, is ruim het dubbele.

Peildatum 1 januari 2017

Dienst	Kosten
Standaard dienstverlening incl. verbindingen naar productie- en ontwikkelomgeving	gratis
Extra verbindingen tot 5 extra ipadressen	€ 1000*
Historische gegevens niet-commercieel, onderzoek en educatief	gratis
Historische gegevens incl. SLA per jaar	€ 1000*

* of 0.1 fte ondersteuning van loketwerkzaamheden

Analyse van koppelvlakken op basis van MonetDB

Sinds het beschikbaar stellen van KV1 (dienstregeling), KV6 (punctualiteit en voertuigposities), KV15 (halteberichten) en KV17 (afwijking op het operationeel proces) door Connexxion aan Calendar42 zijn wij actieve gebruikers geweest van MonetDB om koppelvlakken te analyseren en te verwerken. Dat werkte niet altijd direct zoals we graag wilden, in vijf jaar hebben we de grenzen van menig systeem verkend en vaak ook verlegd. Voorafgaande aan een uitgebreide handleiding deze blog.

Een van de grenzen waar een beginnende KV6 of KV78turbo gebruiker tegen aan loopt is dat huis-tuin-en-keuken databanksoftware vaak niet snel genoeg is om een inkomende datastroom te verwerken en er tegelijkertijd vanaf een andere verbinding vragen over te kunnen beantwoorden. De verwerking vertraagt en er ontstaat een wachtrij die er uiteindelijk voor zorgt dat reisinformatie die wordt getoond minuten ouder is dat de laatst verstuurde gegevens, maar die op dat moment nog niet verwerkt zijn. Verschillende oplossingen zijn binnen handbereik; in plaats van per bericht de databank bij te werken kunnen berichten van meer voertuigen in een keer worden verwerkt.

Ook kan het concept van relationele database overboord worden gegooid. Vaak is alleen de laatste waarde interessant en wordt een koppelvlak gefilterd op een gekozen sleutel om een specifieke doorsnede te maken. In het geval van een OVradar is de primaire sleutel de samengestelde waarde van vervoerdercode en voertuignummer. Wanneer een applicatie voor bushaltes wordt gemaakt is die primaire sleutel de samengestelde waarde van vervoerdercode en haltenummer. De omvang van het maximum aantal sleutels is daarmee vooraf bekend en dat maakt het geheugenbeheer van een actuele reisinformatie server veel eenvoudiger.

Toch is de vraag: Kunnen jullie ook alle reisinformatie doorzoekbaar maken? meermalen gesteld, door hogescholen, universiteiten, overheden, vervoerders en adviesbureaus. Laten we daarom in prioriteit aangeven wat hiervoor van belang is. Als eerste we willen hoe dan ook alle informatie opslaan, een redundante opslag van NDOV koppelvlakken is dan ook een noodzaak. We behandelen onszelf niet anders dan andere afnemers, en sluiten dan ook aan op de pijp die wordt beheerd door ACC ICT, ze noemen zichzelf tegenwoordig specialist in continuïteit en dat is juist hier nodig. Met meerdere ontvangstpunten en samenwerking met meerdere NDOV-afnemers kunnen we alle reisinformatie opslaan die vervoerders uitsturen, ook als we zelf een steekje laten vallen.

Die opslag wordt in eerste instantie gerealiseerd door koppelvlakken van XML-structuur om te zetten naar CSV. Dat ging goed totdat een vervoerder corrupte XML stuurde, daarom wordt corrupte XML in een afzonderlijk bestand opgeslagen. Voor een normale toepassing zou op middernacht een nieuw bestand beginnen een handige methode zijn, echter in het openbaar vervoer loopt de operationele dag van 4 uur ’s ochtends tot ruim 24 uur later. We kunnen ook de structuur van de bestanden inzetten om data partities te maken. De primaire sleutel in KV6 bevat onder andere de vervoerdercode en operationele dag. Het is dus eenvoudig om data naar vervoerder op te splitsen, immers: er bestaat tijdens de latere verwerking geen relatie tussen verschillende vervoerdercodes. Wij hebben er voor gekozen om data weg te schrijven naar een uniek bestand per operationele dag, en later pas doorsnedes te maken per vervoerder. Dat gezegd hebbende, hebben we nog wel een dingetje met open bestanden op te lossen.

Met dagelijkse KV6 en KV17 bestanden ontbreekt een ding om alles aan elkaar te koppelen: een dagelijkse dienstregeling. De verwerking van de verschillende KV1 bestanden per vervoerder kost op zichzelf veel moeite door verschillende versies van de standaard en verschillende geldigheden per vervoerder. We willen er zeker van zijn dat we de laatst geldige dienstregeling van een vervoerder gebruiken. OVapi levert ons iedere dag een uitgeschreven gedenormaliseerde dienstregeling, met alle passeertijden langs alle haltes en stations van Nederland, we noemen dit koppelvlak voor het gemak: TT (Timetable).

Losse bestanden op schijf zijn niet eenvoudig te combineren, daarvoor is een databank nodig. Eens per dag laden we het complete TT bestand als nieuwe tabel. Als naam gebruiken daarvoor de vervoerdercode, het type en de operationele dag, bijvoorbeeld: HTM_TT_20160606. Daarnaast laden we de bestanden die gegeneerd zijn uit KV6 en KV17 gedurende de dag een aantal maal als HTM_KV6_20160606 en HTM_KV17_20160606. In de periode van 00:00 – 08:00 worden twee updates gedaan de operationele dag van gisteren en de nieuwe operationele dag.

Op dit moment hebben we ruim twee jaar data beschikbaar om actief te kunnen bevragen. Een bevraging kan een rijtijdanalyse zijn, maar ook alle vertragingen op een bepaalde halte. Op het eerste oog lijkt onze horizontale partitie, per vervoerder per dag, onhandig om om de hele databank in een keer door te zoeken. Een andere methode maakt slechts 1 tabel per type, waarin alle gegevens worden aangevuld. Als gedachte experiment: stel dat we een combinatie maken tussen tabel TT en KV6, dan wordt deze toepast op de primaire sleutel van KV6 waar vervoerdercode en operationele dag onderdeel van zijn. De volledige tabel moet worden ingelezen terwijl we vooraf weten dat slechts kleine gedeeltes zullen koppelen, een slimme databank zal waarschijnlijk een hash-index maken voor de operatie wordt uitgevoerd. In het geval van onze partities zijn die hash-indices 1/n-dagen kleiner en daarmee sneller te combineren.

Om toch in de volledige databank te doorzoeken kan in de databank programmeertaal SQL gebruik gemaakt worden van een doorsnede, oftewel VIEW. Er is een doorsnede te maken die de verschillende tabellen weer combineert door het UNION ALL commando. Het eerste nadeel is dat een zoek argument op de doorsnede er voor zorgt dat de volledige view moet worden gemaakt, slimme databank optimalisaties zullen er waarschijnlijk voor zorgen dat de argumenten op de verschillende gecombineerde tabellen worden uitgevoerd en het resultaat wordt samengevoegd. Een tweede nadeel van deze methode is dat per dag de VIEW definitie moet worden verwijderd om de nieuwe tabellen te koppelen. Om praktische redenen kan het handig zijn om het databankschema niet te veranderen, bijvoorbeeld wanneer andere tabellen er een afhankelijkheid op hebben.

MonetDB biedt een interessant alternatief voor een klassieke gecombineerde tabel: de MERGE TABLE. Deze gecombineerde tabel heeft een transparante administratie. Tabellen kunnen worden toegevoegd en verwijderd, zonder dat het schema zelf wijzigt. In de afgelopen tijd hebben wij erg veel geëxperimenteerd met deze functionaliteit. Eerlijkheid gebiedt te zeggen dat er al heel wat water door het Rijn-Schiekanaal heeft gestroomd voordat alle eigenaardigheden zijn onderkend, beschouw dit niet als waarschuwing, maar als bevestiging dat het anno juni 2016 prima werkt en alleen nog beter kan worden. Voorgaande beschreef het tweede nadeel, hoe zit het met het eerste nadeel?

TL;DR Sinds vandaag hebben wij MonetDB zo ver dat het alleen de tabellen bekijkt die daadwerkelijk informatie bevat waar we om vragen. Praktisch; stel we hebben twee jaar aan data in onze gecombineerde tabel, en we zoeken op 2 juni dan zal alleen de onderliggende tabel van HTM_KV6_20160602 worden bekeken. Hoe weet MonetDB dan dat het alleen daar moet kijken? Onze tabellen zullen na het aanmaken niet meer veranderen, we kunnen de tabel dan ook als alleen-lezen markeren. Daarna laten we MonetDB de tabel analyseren, vervolgens wordt de geanalyseerde tabel aan de gecombineerde tabel toegevoegd. Op basis van de analyse vooraf kan de MonetDB beslissen dat de tabel binnen of buiten de selectie valt.

Gemiddelde snelheid (warm) na 3x draaien

	totaal aantal regels	analyzed	view	merge table
punctdep filter operatingday en lineplanningnumber	83.715.212	nee	719ms	673ms
punctdep filter operatingday en lineplanningnumber	83.715.212	ja	220ms	11ms
kv6 filter operatingday en lineplanningnumber	548.825.316	ja	267ms	12ms

Machine

CPU	8x Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz
RAM	64GB
Besturingssysteem	Gentoo Linux
Kernel	Linux 4.6.1-gentoo
Opslag	2x SAMSUNG MZ7LN512; SoftRAID 10-far2
Bestandssysteem	F2FS (DBfarm), EXT4 (programmacode)


DROP TABLE kv6;
CREATE MERGE TABLE "sys"."kv6" (
"receive" TIMESTAMP,
"message" TIMESTAMP,
"vehicle" TIMESTAMP,
"messagetype" VARCHAR(10),
"operatingday" DATE,
"dataownercode" VARCHAR(10),
"lineplanningnumber" VARCHAR(10),
"journeynumber" INTEGER,
"reinforcementnumber" SMALLINT,
"userstopcode" VARCHAR(10),
"passagesequencenumber" SMALLINT,
"distancesincelastuserstop" INTEGER,
"punctuality" INTEGER,
"rd_x" INTEGER,
"rd_y" INTEGER,
"blockcode" INTEGER,
"vehiclenumber" INTEGER,
"wheelchairaccessible" VARCHAR(5),
"source" VARCHAR(10),
"numberofcoaches" SMALLINT,
"trip_hash" BIGINT
);

ALTER TABLE kv6_20160605 SET READ ONLY;
ALTER TABLE kv6_20160604 SET READ ONLY;
ANALYZE sys.kv6_20160605;
ANALYZE sys.kv6_20160604;
ALTER TABLE kv6 ADD TABLE kv6_20160605;
ALTER TABLE kv6 ADD TABLE kv6_20160604;


Wereldprimeur voor Nederland op gebied van open data

Brongegevens voor reisinformatie zijn vanaf nu zonder beperkingen in heel Nederland beschikbaar als open data. Nederland is daarmee wereldwijd het eerste land dat deze mijlpaal bereikt. Het gaat daarbij zogeheten ‘realtime’ open data: met de gegevens kunnen reizigers zien of de bus, tram of trein op tijd is of niet. Vervoerbedrijven en OV-autoriteiten verenigd in de netwerkorganisatie NDOV (Nationale Data Openbaar Vervoer) stellen vanaf nu landelijk brongegevens beschikbaar onder een CC0 vrijwaring. Dit betekent dat elke afnemer de data naar eigen inzicht vrij mag (her)gebruiken.

Tot voor kort waren brongegevens slechts beschikbaar voor een bepaald gebied en werden ze alleen vrijgegeven onder bepaalde voorwaarden. Zo mochten de gegevens bijvoorbeeld alleen gebruikt worden voor het verstrekken van reisinformatie. Deze beperkingen zijn door de CC0 vrijwaring opgeheven. Afnemers zijn nu vrij zijn om de brongegevens te kopiëren, aan te passen en te verspreiden, ook als het om commerciële doeleinden gaat zoals het verkopen van analyses.

Nico van Paridon, voorzitter van de stuurgroep NDOV.“Met vereende krachten hebben we een historische mijlpaal bereikt. We zijn er trots op dat we in heel Nederland open data helemaal vrijgeven zonder voorwaarden. Dat is goed voor de vervoerssector en past bij het streven van een transparante overheid. Dat we met dit resultaat ook wereldwijd een primeur hebben is mooi meegenomen. We vergroten hiermee de kans op nieuwe innovaties en we hopen dat velen ons voorbeeld zullen volgen.”

Brongegevens beschikbaar stellen als open data heeft veel voordelen. Het gebruik van deze open data geeft afnemers de vrijheid om diverse analyses uit te voeren. Hierdoor kunnen nieuwe verbanden en relaties zichtbaar worden. Dit kan leiden tot vernieuwingen in het openbaar vervoer en een aantrekkelijker product voor de reizigers. Het stimuleert app bouwers om steeds betere apps te maken voor reizigers. De open data is op internet verkrijgbaar via www.ndovloket.nl en www.9292opendata.org.

Haltetaxi Zeeland op Google Maps

Provincie Zeeland heeft ingezet op twee soorten openbaar busvervoer. Een kernnet dat wordt uitgevoerd door Connexxion en een belbus in de markt gezet als Haltetaxi Zeeland. Complementair aan het bestaande openbaar vervoer, telefonisch bestelbaar en toch van halte naar halte. De Haltetaxi maakt gebruik van een virtuele dienstregeling, ritten rijden immers alleen op bestelling en sommige bestellingen worden exclusief uitgevoerd als rolstoel­vervoer. Met die kanttekening lijkt de vorige week gepubliceerde ritten­planning verder verdacht veel op een echte dienstregeling, met echte haltes en echte tijden en echte afstanden. De kwaliteit van de reisinformatie valt echter tegen.

De dienstregeling wordt door Provincie Zeeland niet gepubliceerd in een gestandaar­diseerd formaat, maar in een Excel sheet. Daarnaast bevat de spreadsheet een significant aantal semantische en inhoudelijke fouten die van invloed zijn op het juist hergebruik in reisplanners en actuele reisinformatie apps. Zo wordt van veel van de haltes gesuggereerd dat ze uit het Centraal Halte Bestand komen, wat na controle niet zo blijkt te zijn. Gezien de publicatie al in september 2015 beschikbaar is gesteld aan een derde moet de provincie op de hoogte zijn van de fouten. Op de vraag hoe de fouten het best inhoudelijk konden worden geregistreerd kwam geen reactie.

Vorige week is door een afnemer van ons loket al een GTFS gepubliceerd om de eerste drempel over te gaan: het daadwerkelijk kunnen gebruiken van de haltetaxi informatie in reisplanners. Vanaf vandaag is kan iedere Zeeuw ook gewoon gebruik maken van Google Maps en iedere Belg overigens ook.

 

NDOVloket.nl eerste loket met premium monitoring

Stichting OpenGeo is een strategische samenwerking aangegaan met de Nederlandse Spoorwegen (NS). NS bewaakt als nieuwe afnemer van NDOVloket.nl alle actuele datastromen die OpenGeo namens de vervoerders beschikbaar maakt. De dienstverlening is meegenomen in de gouden SLA die beide partijen aan reisinformatiediensten wensen te leveren.

NS: „NDOVloket.nl is het eerste NDOV loket waar wij binnen een week succesvol mee konden verbinden.” OpenGeo: „Initieel was de bedoeling dat NS alleen haar eigen datastromen ging bewaken, maar men zag bij NS de toegevoegde waarde van volledige ketenbewaking, van begin tot eind.”

Nu NS kwantitatieve gegevens verzamelt kan ook informatie worden terug geleverd over de kwaliteit van de verbinding en het aantal gemiste berichten. Met de nieuwe benadering maakt NS inzichtelijk waar in het reisinformatielandschap problemen ontstaan. Hiermee kan proactief worden gereageerd bij verstoringen in de keten.

Decentrale infrastructuur en CC0

In de afgelopen week was het bij een van onze leveranciers weer meer malen raak; korte en langere onderbrekingen hebben er voor gezorgd dat de levering van een aantal vervoerders, tegelijkertijd, werden onderbroken. Met het oog op de nabije toekomst, waar ND-OV gegevens als echte open data worden gepubliceerd, kunnen we ons niet blijven verschuilen achter formulieren en firewalls. De drempel om toegang te krijgen tot gegevens moet lager, maar het moet wel voor iedereen blijven werken.

Onze samenwerking met ACC ICT B.V. geeft ons de ruimte om in alle rust verder te experimenteren. De twee virtuele machines die de gegevens naar afnemers van ndovloket.nl sturen passen nog steeds als bijlage in een e-mail bericht. En we weten uit benchmarks in het verleden dat onze infrastructuur prima op een ARM-server kan draaien. We hebben in de afgelopen maanden dan ook uitgebreid getest op Scaleway een leverancier van baremetal cloudoplossingen.

ARM processoren zijn energie efficiënt, wat een groen gevoel van binnen kan geven. Leuker werd het toen de bevestiging kwam dat we over het interne cloudnetwerk efficiënt verkeer konden versturen – ook naar andere klanten – en dus potentiële afnemers. Door een enkele rechtstreekse verbinding over het internet naar onze vaste infrastructuur, kunnen afnemers op diezelfde cloud, gebruik maken van een lokale pubsub.

En zo hebben we, zonder al te veel moeite, de eerste stap gezet naar een Content Delivery Network voor real-time open data.

Reisinformatie van Texelhopper ook in het loket

In de pauze van het Movinnio Congres afgelopen donderdag spraken wij over het Texelhopper product met projectbeheerder Florien Molendijk. Gisteren is daarop door Provincie Noord-Holland de eerste informatie beschikbaar gesteld, waarna afnemers direct aan het werk gingen om van een Excelsheet reisinformatie te maken.

De Texelhopper is een speciale pilot waarbij openbaar vervoer vraaggestuurd wordt ingezet. Door middel van een eigen dynamische routeplanner kan een reiziger een rit reserveren. De ritten vertrekken in tegenstelling tot taxi of WMO-vervoer van vaste haltes in een regelmatig patroon.

Met de eerste publicatie zijn het netwerk van haltes en de virtuele dienstregeling uitgewisseld. Het is ons streven om ook actuele beschikbaarheid en de mogelijkheid om naar een reservering pagina door te verwijzen aan te kunnen te bieden. Gelukkig zijn de tarieven eenvoudig: iedere rit kost drie euro.

Enige opmerkingen bij het bestand door de producent:

Het tablad met de matrix VanHalte-NaarHalte bevat een kolom VertrekUur met hierin de vertrekuren. Hierbij zijn de 1e 2 uren afhankelijk van de dienstregeling van de TESO. Zie de letters ‘a’ en ‘b’ bij de 1e 2 uren.

• a – komt te vervallen iedere zondag in de periode april t/m augustus
• a+b – komen te vervallen op zondag in de periode september t/m maart

Het bestand is voor afnemers te vinden via http://data.ndovloket.nl/texelhopper/.

Update 27 september 2015: De Texelhopper is ook al te vinden op Google Maps.

Google Maps met Texelhopper

Tarieven NDOVloket.nl in 2016

Veel vragen rond de aanmelding van ons loket gaan over de kosten die jaarlijks worden gerekend. Om de informatie te verduidelijken stellen we onze tarieven jaarlijks vast voor het komende jaar. Deze tarieven worden drie maanden voor de ingangsdatum gepubliceerd.

Peildatum 1 januari 2016

Dienst	Kosten
Standaard dienstverlening incl. verbindingen naar productie- en ontwikkelomgeving	gratis
Extra verbindingen tot 5 extra ipadressen	€ 1000*
Historische gegevens niet-commercieel, onderzoek en educatief	gratis
Historische gegevens incl. SLA per jaar	€ 1000*

* of 0.1 fte ondersteuning van loketwerkzaamheden

Dienstregelingen van WPD en Wadtaxi nu beschikbaar in XML

In samenwerking met Wagenborg heeft Stichting OpenGeo een databasekoppeling tot stand gebracht welke de dienstregeling van zowel Wagenborg Passagiers Diensten als Wadtaxi tot drie maanden vooruit kan ontsluiten in een gestructureerd formaat. In dit XML formaat zullen op korte termijn ook extra afvaarten worden toegevoegd.

Tot vandaag moesten afnemers het doen met een PDFje die de dienstregeling bevatte, en “PDF mailtjes” om extra afvaarten aan te kondigen. Afnemers moesten deze data dan overschrijven om er een bruikbare dienstregeling van te maken. Samen met Wagenborg bouwen we verder. Er zullen nog enkele wijzigingen worden doorgevoerd om de informatie beter bruikbaar te maken in realtime systemen voor actuele reisinformatie.

De overtocht van een Wadtaxi is drie keer zo snel dan een reguliere overtocht. De meest disruptieve stap van de koppeling is de ontsluiting van de actuele bezetting. Wagenborg stelt afnemers van ons loket in staat om te tonen hoeveel plek er nog is op reeds geplande Wadtaxi’s. Wagenborg is hiermee de eerste vervoerder die gegevens over de actuele bezetting vrij geeft. De reiziger profiteert overigens het meest: hoe beter de bezetting, des te lager de prijs van een snelle overtocht.

OpenGeo heeft er voor gekozen om de ruwe data te exporteren, zoals zij die rechtstreeks ontvangen van de vervoerder. Serviceproviders kunnen deze gegevens omzetten naar een formaat dat de markt meer aanspreekt, zoals GTFS.